feat(projects): add agent and CLI project-home support - #6590

Cassandra security/adversarial re-review — adff0acff7f5fbe61795aad6e3a5670e1300b45d

Verdict: merge-ready from my lane. No actionable findings.

I reviewed the full 2e0fe6999..adff0acff diff before tracing the surrounding Projects submit path, Tauri command boundary, relay scope helpers, explicit-key submission helper, workspace state snapshots, and mock bridge. The remaining tenant-scope blocker is closed:

• ProjectAgentChatPanel.tsx:168-175 passes the callback-captured relay and signer scopes into project-home membership.
• channels.rs:546-552 resolves one relay base and one signable key snapshot, then validates both captured scopes before mutation.
• channels.rs:572 submits with submit_event_at_with_keys(builder, &state, &relay_base, &signing_keys), so neither relay nor signer is re-read after validation.
• e2eBridge.ts:7419-7426 applies both checks after the injected delay, matching the race shape rather than checking too early.

Adversarial scenarios checked: switch before relay resolution; identity swap between relay and key reads; switch after validation; malformed/empty optional scopes; multi-member partial failure; restored-DM guard interaction; membership failure before message send; and mismatch behavior in the mock bridge. The fixed snapshot either fails closed before publication or publishes only with the captured relay/key pair.

Independent verification at exact HEAD:

• Desktop full test suite: 5,451 passed.
• Tauri relay::scope::tests: 11 passed.
• git diff --check: clean.

Residual/testing gap (recorded here durably): I did not exercise a live relay-backed community switch during an in-flight membership request. The production call path and deterministic delayed bridge cover the relevant ordering, and I do not consider this merge-blocking.

Gauge correctness/testing verification of Jude's three P1s — all confirmed at exact head adff0acff7f5fbe61795aad6e3a5670e1300b45d

Independent source verification, formed before reading other responders. All three mechanisms are real; none is speculative. For each, the answer to "which test would fail if this were wrong?" is currently none — that is itself the coverage finding.

1. ensure_default_create_repo reuses a same-slug repo with no binding check — confirmed, confidence 100

crates/buzz-cli/src/commands/projects.rs:665-670:

    let repo_id = repo_id_from_project_slug(slug)?;
    if fetch_own_repo_announcement(client, &repo_id)
        .await?
        .is_some()
    {
        return Ok(repo_id);
    }

The issue-time path already enforces the invariant this skips — crates/buzz-cli/src/commands/project_channel.rs:197-200:

    if let Some(existing) =
        crate::commands::repos::fetch_own_repo_announcement(client, &repo_id).await?
    {
        require_repo_channel_binding(&existing, channel)?;

So buzz projects create app --channel B publishes a channel-B project whose member repo is bound to channel A (or unbound), and the divergence surfaces later as an ACP/CLI routing conflict rather than at creation time. Required regression (must fail on today's code): create-with-existing-repo where the repo's first buzz-channel (a) mismatches → Conflict before project publication; (b) is absent → Conflict; (c) matches → reuse succeeds.

2. Permanent caching of None and of mutable project metadata — confirmed, confidence 100

crates/buzz-acp/src/pool.rs:598-610 (lookup_project) returns any cached entry — including a cached None (cache.get(&channel_id).cloned() yields Some(None) → return cached;) — and inserts fetched.clone() unconditionally with no TTL. The projects map (pool.rs:547) is a separate Arc<RwLock<HashMap>> with no invalidation path: invalidate_channel / invalidate_channel_sessions operate on session state only and never touch it. The fetch helper documents absence as final: pool.rs:2988 — "Empty results are not retried: most channels are not project homes." Consequence: resolve channel before project creation → Project block unavailable until process restart; renames/default-repo changes similarly frozen. Required regression: None resolved → project published → subsequent turn (same process) carries the Project block.

3. Truncated 1,000-row page treated as authoritative absence — confirmed, confidence 100

• ACP fetch_project_home_for_channel, pool.rs:2993-3003: "kinds": [KIND_PROJECT], "limit": 1000 — no tag filter at all; channel matching is client-side, so the page is all listed projects relay-wide.
• CLI fetch_projects_for_channel, crates/buzz-cli/src/commands/projects.rs:74-86: same shape, client-side project_tags_match_channel post-filter.
• CLI fetch_channel_repos, project_channel.rs:161-166: uses #buzz-channel, but the relay pushes only #p/#d into SQL (crates/buzz-relay/src/handlers/req.rs:1001-1044); custom-tag matching happens after the LIMIT-clamped read (req.rs:957-960, api/bridge.rs:1308-1315).

Past 1,000 newer visible heads, an older authoritative project/repo silently drops out; the caller concludes "not a project home" or takes default-repo fallback. Compounding interaction worth naming: a starvation-induced false absence from (3) is then cached permanently by (2) — a transient load condition becomes a sticky wrong answer for the process lifetime. Required regression: authoritative head seeded beyond page one → resolver either finds it (pagination; BuzzClient composite cursor exists at crates/buzz-cli/src/client.rs:683-729) or fails explicitly on truncation — never a silent absence.

Verified clean / scope

I re-derived each claim from the head sources quoted above; I did not re-run the suites (Jude's exact-head runs and the green check-runs at adff0ac stand). Negative claims here are scoped to the files and line ranges cited. Wrench owns the fixes; I will re-review the incremental diff when it lands, gating on the three regressions above failing-before/passing-after.

— Gauge (correctness/testing/reliability lane)

Cassandra security/adversarial response to Jude's review — exact head adff0acff7f5fbe61795aad6e3a5670e1300b45d

Verdict: all three requested changes are valid; the current head needs work. I formed this assessment from the full diff and surrounding call paths before reading the other creature reports.

1. Same-slug repository reuse breaks the channel authority invariant — confidence 100.

   crates/buzz-cli/src/commands/projects.rs:665-670 currently says:

       if fetch_own_repo_announcement(client, &repo_id)
           .await?
           .is_some()
       {
           return Ok(repo_id);
       }

   This returns an existing repository without applying the require_repo_channel_binding check already used by issue-time routing. A repository bound to channel A, or with no binding, can therefore be published as channel B's default member and leave project creation reporting success while ACP later rejects the project home. The creation path must fail before project publication unless the first buzz-channel binding equals the requested channel.

2. Permanent positive/negative ACP caching makes mutable authority metadata stale — confidence 100.

   crates/buzz-acp/src/pool.rs:604-610 currently says:

       if let Some(cached) = self
           .projects
           .read()
           .ok()
           .and_then(|cache| cache.get(&channel_id).cloned())
       {
           return cached;
       }

   Because the map stores Option<PromptProjectInfo>, this permanently returns cached absence as well as stale positive metadata. Resolve-before-create therefore suppresses the Project block until process restart; later repository/default changes are also invisible. Bounded freshness or relevant-event invalidation is required, including a None -> project regression without restart.

3. A one-shot, post-filtered page cannot establish absence — confidence 100.

   crates/buzz-relay/src/api/bridge.rs:1308-1315 currently applies the complete filter only after the limited database read:

               for se in stored_events {
                   if !event_in_accessible_channel(&se, &accessible_channels) {
                       continue;
                   }
                   if !buzz_core::filter::filters_match(std::slice::from_ref(filter), &se) {
                       continue;
                   }

   #buzz-channel is not pushed into that SQL read at the reviewed head. More than 1,000 newer nonmatching heads can hide the older authoritative repository/project and produce false absence.

   Implementation constraint: ordinary response-length pagination does not fix the custom-tag case by itself. If a 500-row underlying DB page post-filters to zero matches, a client that treats page.len() < 500 as EOF stops immediately and never advances to the older candidate rows. The fix must either push the exact buzz-channel predicate into SQL before LIMIT, or expose an underlying-scan cursor/exhaustion signal independent of filtered response length. Any exhaustive scan must also have a defined bound and fail explicitly when that bound is exceeded; otherwise attacker-controlled relay history becomes unbounded prompt-path memory/time work.

I reviewed only exact pushed head adff0acff; the implementation work is still in progress and is not covered by this verdict. I will re-review the exact pushed revision, including bound behavior and the starvation regression, when it lands.

Cassandra security/adversarial re-review — exact head e1b1f1b8f7a20cda01a6c4116cd6a22dce79f440

Verdict: no actionable security/adversarial findings in the incremental fix. Jude's three P1 mechanisms are closed at this head.

I reviewed the full adff0acff..e1b1f1b8f incremental diff first, then traced the affected ACP resolver/cache, HTTP bridge filter construction and post-filtering, DB query builder/order-limit path, CLI pagination, project creation, and repository-binding authority checks.

Verified closure:

• Existing default-repository reuse now calls require_repo_channel_binding before returning (crates/buzz-cli/src/commands/projects.rs:677-679), so mismatched and absent bindings fail before project publication.
• Positive and negative project-home cache entries carry a fetch timestamp and expire after 30 seconds (crates/buzz-acp/src/pool.rs:604-624).
• ACP and CLI historical scans use (until, before_id) pagination and probe one event past the 10,000-event bound, failing explicitly rather than treating truncation as absence (crates/buzz-acp/src/relay.rs:443-481; crates/buzz-cli/src/client.rs:731-749).
• A single exact raw #buzz-channel value is extracted into EventQuery.custom_tag (crates/buzz-relay/src/api/bridge.rs:277-283,1376-1378), and DB JSONB containment is applied before ORDER/LIMIT (crates/buzz-db/src/event.rs:504-508). This closes the post-filter/short-page starvation defect in the original pagination attempt.
• Malformed or multi-value #buzz-channel does not receive the optimization; the normal Nostr post-filter remains in place, so this is fail-safe rather than an authorization bypass.

Adversarial scenarios checked: older authoritative head behind unrelated newer rows; same-second composite-cursor ties; exactly 10,000 versus 10,001 results; empty/short/full filtered pages; malformed response event IDs/timestamps; mismatched, missing, and duplicate repository bindings; stale positive and negative cache entries; partial failure between project and repo scans; custom-tag SQL parameterization; and interaction with the existing result-level access/auth filters.

Independent exact-head verification:

• cargo test -p buzz-acp -p buzz-cli passed.
• git diff --check e1b1f1b8f^..e1b1f1b8f passed.
• GitHub reports the PR head at the reviewed SHA.

Residual/testing gaps recorded here durably:

1. I did not seed a live Postgres relay with an authoritative head beyond page one; the fix is established from bridge/DB/client control flow and unit coverage.
2. The new DB custom_tag containment branch is covered indirectly by the query-builder suite, but the Postgres-required tests were not available in my local exact-head run.
3. GitHub's Unit Tests job is currently red while the workflow is still running; GitHub has not exposed the failed-job log yet. My local ACP+CLI package suites pass, so this report does not classify that CI failure until its log is available.

Gauge re-review — correctness/testing/reliability (exact head e1b1f1b8f7a20cda01a6c4116cd6a22dce79f440)

Re-review of the incremental fix commit 8b1d7e7a5 ("fix(projects): refresh and exhaust project lookups") plus the merge of origin/main. All verification below was done against the fetched immutable SHA e1b1f1b8f in a detached worktree.

Verdict on the three P1s: all three are fixed at this head

P1-1 — same-slug repo reuse now enforces channel binding. FIXED, confidence 100.
crates/buzz-cli/src/commands/projects.rs:677-679:

    if let Some(existing) = fetch_own_repo_announcement(client, &repo_id).await? {
        require_repo_channel_binding(&existing, channel)?;
        return Ok(repo_id);

The helper was lifted to pub(crate) and now also rejects the unbound case (project_channel.rs:186-189 returns Conflict on None), and the unit test gained that case (project_channel.rs:415-419). All three regression shapes I asked for exist: foreign binding → Conflict, no binding → Conflict, matching → Ok (existing_repo_must_bind_requested_channel, project_channel.rs:394-420). The binding check runs before build_project/submit_project (projects.rs:390 precedes the build at projects.rs:395), so the Conflict fires before the project is published.

P1-2 — ACP project cache now expires, both positive and negative entries. FIXED, confidence 100.
crates/buzz-acp/src/pool.rs:545-550:

struct CachedProjectInfo {
    fetched_at: std::time::Instant,
    value: Option<PromptProjectInfo>,
}
const PROJECT_INFO_CACHE_TTL: std::time::Duration = std::time::Duration::from_secs(30);

and the read path filters on freshness (pool.rs:610: .filter(|cached| cached.fetched_at.elapsed() < PROJECT_INFO_CACHE_TTL)). The regression test I asked for exists and is the right shape: expired_absence_refreshes_to_project_without_restart (pool.rs:8460) seeds an already-expired None entry and asserts the resolver refreshes to the project — on the pre-fix code this test fails (the old map returns the cached None unconditionally). The fetch path retains CONTEXT_FETCH_TIMEOUT + fetch_with_retry per page (pool.rs:3016-3017), so the prompt path stays bounded.

P1-3 — 1,000-row false absence. FIXED at all three call sites, plus the relay-side starvation defect. Confidence 100.

• CLI: both fetch_channel_repos (project_channel.rs:167-168) and fetch_projects_for_channel (projects.rs:85-86) now use query_all_bounded(filter, PROJECT_QUERY_EVENT_BOUND); bound-hit is an explicit error, not absence (client.rs:744-748: if events.len() > max_events as usize { return Err(...) }, with the max_events + 1 probe at client.rs:740).
• ACP: fetch_project_home_for_channel loops query_raw_all (pool.rs:3017), which pages on the composite (until, before_id) cursor and errors above 10,000 accumulated events (relay.rs:443-481). I hand-traced the loop's boundary arithmetic: exactly 10,000 matching events succeed (final 1-event probe returns empty), 10,001 errors. Correct.
• Relay: the post-LIMIT starvation Cassandra flagged is genuinely closed for the single-value case — extract_buzz_channel (bridge.rs:277-283, gated to exactly one string value) maps into EventQuery.custom_tag (bridge.rs:1376-1378), and buzz-db applies the JSONB containment before ORDER/LIMIT (event.rs:504-508), mirroring the adjacent e_tags clause. The bridge's phase-3 filters_match post-filter (bridge.rs:1439, buzz-core/src/filter.rs:67-79) still enforces the predicate independently, so the pushdown is a starvation fix layered under an unchanged correctness gate — the right shape.

Findings

F1 — CI Unit Tests is FAILING at this exact head; no green rust unit-test CI gate exists for e1b1f1b8f. Severity: blocking for merge, confidence 100 (cause: known infra, confidence 100).
gh api repos/block/buzz/commits/e1b1f1b8f.../check-runs → {"conclusion":"failure","name":"Unit Tests"} (job 97554786238). The log dies during dependency compilation: error: could not find native static library 'sherpa-onnx-c-api' → could not compile sherpa-onnx-sys → Recipe 'test-unit' failed. This is the documented poisoned-rust-cache failure (buzz-voice / sherpa-onnx-sys fingerprint kept while prebuilt libs pruned), not this PR — but it means zero rust unit tests executed in CI at this head. The job needs a cache-delete + rerun and a green result before merge; the durable cache-directories fix is still outstanding.

To partially close that gap I ran locally at e1b1f1b8f: cargo test -p buzz-acp -p buzz-cli -p buzz-db -p buzz-relay --lib → buzz-acp 810 passed / 0 failed, buzz-cli 374 passed / 0 failed, buzz-db 105 passed / 192 ignored (Postgres-required), buzz-relay 903 passed / 8 failed / 47 ignored. The 8 buzz-relay failures are environmental, not this PR: all panic at media.rs:1001 seed relay.example community for host-bound media tests: Sqlx(PoolTimedOut) (no local Postgres), and git diff --name-only <merge-base>..e1b1f1b8f -- crates/buzz-relay/src/api/media.rs crates/buzz-relay/src/api/admin.rs is empty. Scoped claim: I have not seen these 8 pass anywhere at this head; only a green CI rerun proves them.

F2 — the load-bearing SQL pushdown clause has no executing test. Severity: medium (coverage), confidence 100 on the absence (scoped to this workspace's rust sources).
rg -n "custom_tag" crates/buzz-db/ matches only the three implementation lines (event.rs:75, event.rs:134, event.rs:504); no test anywhere in crates/ references EventQuery.custom_tag. The only new relay test is extract_buzz_channel_requires_one_string_value (bridge.rs:3263), which tests filter parsing, not the SQL. If the containment clause at event.rs:504-508 were malformed or dropped, no test would fail — the phase-3 post-filter would silently restore correctness while reintroducing the exact starvation this commit exists to fix. This needs a Postgres-backed buzz-db test: N newer non-matching 30617 heads > page limit, one older matching head, assert the matching head is returned within one page.

F3 — no test places the authoritative head beyond page one (Jude's explicit ask), and query_raw_all's pagination loop is entirely untested. Severity: medium, confidence 100 on the absence (scoped to crates/).
rg -n "query_raw_all" crates/ → only relay.rs:443 (impl) and pool.rs:3017 (caller). The new ACP regression test (pool.rs:8460) serves single-page responses, so cursor advancement, the done = page.len() < page_limit EOF rule, the 10,000-bound error, and multi-page assembly in fetch_project_home_for_channel all execute zero times under test. Same for the CLI side: advance_query_cursor has unit tests (client.rs:2333-2358, pre-existing), but query_all_bounded's bound-exceeded error path has none. The loop logic traced correct by hand, but a future off-by-one regresses silently.

F4 — at the ACP boundary, the 10,000-event bound degrades to cached absence, not an error. Severity: low, confidence 75.
query_raw_all fails closed (relay.rs:456-460 returns Err), but its only caller converts every error to None via retry-then-give-up (pool.rs:3016-3030: Ok(Err(e)) => { ...will retry... None }), and lookup_project caches that None for 30s (pool.rs:615-623). So "fail closed above 10,000" holds in the CLI (hard error, client.rs:744-748) but in ACP a bound-hit reads as "channel has no project" for the next 30s. Graceful degradation on the prompt path is a defensible choice — but it is the documented anti-goal ("bound-hit must not read as absent") at one of the two consumers. At minimum this deserves a tracing::warn! distinct from ordinary fetch failure; today both collapse into the same debug line.

F5 — TTL expiry has no stale-value fallback: a transient relay failure after expiry replaces a known-good project with None for 30s. Severity: low, confidence 75.
pool.rs:614-623: fetched (which is None after both retry attempts fail) is unconditionally inserted over the previous entry. Pre-fix, a resolved project was immune to transient relay blips (permanent positive cache); now a 2×3s-timeout window at refresh time silently drops the Project block from prompts for the following 30s. Keeping the expired value on fetch failure (refresh-on-success, expire-only-on-success) would preserve the old resilience without the old staleness.

F6 — the P1-1 fix is enforced at an untested call site. Severity: low, confidence 75.
The binding test covers the pure helper require_repo_channel_binding; nothing tests that ensure_default_create_repo (projects.rs:677-679) actually calls it — delete that line and cargo test -p buzz-cli still passes (no BuzzClient mock harness exists in buzz-cli; scoped: rg -n "ensure_default_create_repo" crates/buzz-cli → projects.rs:390 and projects.rs:669 only). Same shape at the second call site ensure_default_repo (project_channel.rs:205-208). Acceptable residual given the missing harness, but it should be named, not assumed covered.

Verified clean (scoped)

• Boundary arithmetic of both pagination loops (relay.rs:445-481, client.rs:735-749) hand-traced: exact-bound success, bound+1 error, cursor advance on full pages, malformed cursor fields rejected (relay.rs:466-475).
• The #buzz-channel multi-value case (2+ values) deliberately skips pushdown (bridge.rs:280: .filter(|values| values.len() == 1)) and falls back to post-filter; both production callers (pool.rs:3010, project_channel.rs:165) send exactly one value, so no live path re-enters the starvation regime.
• The author_gate_tests request-count updates (2→3) match the new two-filter fetch shape; not a weakened assertion.
• Pre-publish ordering of the P1-1 Conflict (binding check at projects.rs:390 precedes build_project/submit_project at projects.rs:395+).
• Negative claims above are scoped to rg sweeps of crates/ at e1b1f1b8f; I did not audit desktop/TS surfaces.

Bottom line

All three P1 mechanisms are correctly fixed with the right regression shape for P1-1 and P1-2. Merge should wait on exactly one thing: a green Unit Tests CI run at this head (F1 — currently failing on known-infra sherpa-onnx cache poisoning, so the rust suites have not executed in CI at all for this SHA). F2/F3 are the coverage residuals I'd file as follow-up issues rather than block on; F4/F5/F6 are named residuals for the implementer's judgment.

Cassandra adversarial re-review of e1b1f1b8f — Jude's two new P1s are valid

I independently traced both mechanisms before using Jude's report as corroboration. Both are actionable at exact head e1b1f1b8f7a20cda01a6c4116cd6a22dce79f440.

P1 — failed ACP project discovery becomes cached ordinary-channel context (confidence 100)

Evidence

• crates/buzz-acp/src/pool.rs:3004-3007 globally enumerates all projects rather than using the now-supported channel predicate:

  serde_json::json!({
      "kinds": [buzz_core::kind::KIND_PROJECT],
  }),

• crates/buzz-acp/src/pool.rs:3016-3035 converts query errors, the 10,000-event bound, and timeout into None, then exits the function through await?:

  let mut page_events = fetch_with_retry(|| async {
      match timeout(CONTEXT_FETCH_TIMEOUT, rest.query_raw_all(filter.clone())).await {
          Ok(Ok(events)) => Some(events),
          Ok(Err(e)) => { /* ... */ None }
          Err(_) => { /* ... */ None }
      }
  })
  .await?;

• crates/buzz-acp/src/pool.rs:614-623 then stores that indistinguishable None as a fresh cache entry:

  let fetched = fetch_project_home_for_channel(channel_id, &self.rest_client).await;
  if let Ok(mut cache) = self.projects.write() {
      cache.insert(channel_id, CachedProjectInfo {
          fetched_at: std::time::Instant::now(),
          value: fetched.clone(),
      });
  }

Trigger: a relay with >10,000 listed project heads, or one that cannot finish the global paginated scan inside three seconds, makes both retries fail. resolve() still returns channel metadata with project: None, and that unproven absence is reused for 30 seconds. The generated session is therefore told it is in an ordinary channel even though discovery failed.

Required shape: push #buzz-channel into the project query as candidate reduction, and represent discovery as at least Result<Option<PromptProjectInfo>, _> so only a successful empty result is negatively cached. A failure must retain stale known-good data or propagate an indeterminate/error state; it must not become authoritative absence. Add a causal bound/timeout regression and an authoritative-head-beyond-page-one regression.

P1 — default-repository write outcome is discarded before project publication (confidence 100)

Evidence

• crates/buzz-cli/src/commands/projects.rs:692-694 ignores the addressable write response and returns the coordinate:

  let event = client.sign_event(builder)?;
  client.submit_event(event).await?;
  Ok(repo_id)

• crates/buzz-cli/src/commands/projects.rs:390-405 immediately advertises that coordinate in the new project:

  let repo_id = ensure_default_create_repo(client, slug, name, description, home).await?;
  members.push(expand_repo_coord(&repo_id, &caller_pubkey)?);
  // ...
  submit_project(client, builder, /* ... */).await

• The repository command's existing contract shows the missing check at crates/buzz-cli/src/commands/repos.rs:189-199:

  parse_write_response(raw, "repository changed concurrently; fetch the latest rules and retry")
  // ...
  let raw = client.submit_event(event).await?;
  println!("{}", validate_write_response(&raw)?);

Trigger: two clients for the same signer both preflight no repo and submit competing (pubkey, 30617, slug) heads. This invocation can receive accepted: true, message: "duplicate: ..." for a dominated write; because the body is ignored, it still publishes and reports a project pointing at the other winning repository, which may be unbound or bound to another home. A later winning head between acceptance and project publication creates the same inconsistency unless the live head is re-read.

Required shape: parse the write response and reject a duplicate/dominated write, then re-read the winning repository head and verify its binding immediately before publishing the project. Recovery should be idempotent: an already-live, correctly bound same-slug repository is success; any absent/mismatched winner is a conflict and the project must not publish. Add a deterministic dominated-write/concurrent-head regression.

Verdict: needs work. These are integrity/correctness blockers in ACP context generation and multi-event project publication. Report-only; I made no source changes.

Residual verification gaps: I did not run a live seeded >page-one relay or a two-client race. Those gaps do not reduce the control-flow findings, but the author-owned causal regressions should cover both failure shapes before re-review.

Gauge correctness/testing verification of Jude's round-3 review — exact head e1b1f1b8f7a20cda01a6c4116cd6a22dce79f440

Independent source verification against the fetched immutable SHA, formed before reading any other creature response to this round. Both new P1 mechanisms are real. Both are author-actionable. Neither has a test that would fail today.

P1-A confirmed — ACP converts discovery failure into cacheable, authoritative absence (confidence 100)

Three links in the chain, each verified:

1. Failure collapses to None via ? — crates/buzz-acp/src/pool.rs:3016-3035: the per-filter fetch is fetch_with_retry(|| async { match timeout(CONTEXT_FETCH_TIMEOUT, rest.query_raw_all(filter.clone())).await { ... } }).await?; — fetch_with_retry returns Option, and ? in fetch_project_home_for_channel (returns Option<PromptProjectInfo>, pool.rs:3000-3003) makes a timeout, a relay error, or the query_raw_all 10k-bound error (relay.rs:456-459: return Err(RelayError::Http(format!("query exceeded the exhaustive {EVENT_BOUND}-event bound")))) indistinguishable from "no project".
2. That None is cached — pool.rs:614-623: let fetched = fetch_project_home_for_channel(...).await; then cache.insert(channel_id, CachedProjectInfo { fetched_at: ..., value: fetched.clone() }) unconditionally. A failure-derived None is served as proven absence for the 30s TTL, and the session it seeds gets ordinary-channel context permanently.
3. The project filter still lacks #buzz-channel — pool.rs:3005-3007: serde_json::json!({ "kinds": [buzz_core::kind::KIND_PROJECT], }) — a global kind-30621 enumeration, even though this head added exact single-value #buzz-channel SQL pushdown and uses it for the repo filter one expression later (pool.rs:3008-3011). build_project writes the buzz-channel tag on project events (crates/buzz-sdk/src/builders.rs:2293-2295), and pick_authoritative_project_home matches on that same channel id, so filtering is safe and removes the global-scan exposure entirely.

Which test would fail if this were wrong? None. The resolver tests around pool.rs:8490-8560 exercise refresh-after-TTL and cached-success paths; no test asserts that a failed/indeterminate lookup is distinguishable from proven absence. This escalates my filed residuals F4 (10k-bound-hit cached as absence) and F5 (TTL refresh drops a known-good project on transient failure) from follow-up to required — Jude's mechanism subsumes both, adding the timeout leg and the missing pushdown.

P1-B confirmed — repository write response discarded before project publication (confidence 100)

crates/buzz-cli/src/commands/projects.rs:692-694:

let event = client.sign_event(builder)?;
client.submit_event(event).await?;
Ok(repo_id)

The relay write response is discarded. Contrast the project path in the same file — projects.rs:259: let response = parse_write_response(&raw, "project changed concurrently; retry")?; — and the delete path (projects.rs:654) which parses AND re-reads the winning head afterward. The repo step does neither: a dominated/duplicate write (concurrent same-identity create racing the (owner, 30617, slug) replaceable head) still lets cmd_create publish the project at projects.rs:390-405 advertising a default-repo coordinate whose winning head may be bound elsewhere or unbound. The preflight at projects.rs:677-679 is check-then-act; nothing verifies the post-write state.

Which test would fail? None — no test in projects.rs submits a dominated repo write and asserts create fails.

New merge gate — PR is CONFLICTING with main (confidence 100)

GitHub reports mergeable: false, mergeable_state: dirty. Verified locally: git merge-tree --write-tree e1b1f1b8f origin/main (merge-base db5617dd1) conflicts in desktop/src/features/channels/ui/ChannelPane.tsx and desktop/src/features/channels/ui/FocusThreadDrawer.tsx. Main moved after the last update; a rebase/merge is required regardless of the two P1 fixes, and CI must re-run at the new head.

Verified clean at this head (scope: the round-3 claims I checked)

• Jude's line citations all match the actual source at e1b1f1b8f — no misquotes.
• The round-2 fixes remain intact: binding guard (projects.rs:677-679), 30s TTL both polarities (pool.rs:604-623), composite-cursor pagination with fail-closed bound (relay.rs:443-459), pre-ORDER/LIMIT JSONB pushdown on the repo filter.
• The sherpa-onnx Unit Tests failure was cleared by cache delete + rerun (attempt 3 green); it is not evidence about this diff either way.

Required regressions for the fix commit (the tests that must fail on today's code)

1. Mock relay returns an error/timeout for the project lookup → assert the session does NOT receive ordinary-channel context and no None enters the cache.
2. Mock relay holds the authoritative project beyond page one of the (now #buzz-channel-filtered) query → assert it is found.
3. Repo submit returns a dominated write response → assert projects create fails before publishing the project event.

Fixes are the author's; I will re-review the incremental diff at the next exact pushed head.

Cassandra security/adversarial re-review — exact head 86bf4946b59fd7a958fbb695919653dc33e51350

Verdict: needs work on the requested causal regressions; I found no new production-code security defect in the incremental fix.

I reviewed the full e1b1f1b8f..86bf4946b correction delta, then traced the ACP resolver/cache call paths, default-repository create/write/re-read path, and both desktop conflict resolutions. I also independently reran the full affected package suites at this exact SHA:

• cargo test -p buzz-acp -p buzz-cli — passed
• just desktop-test — 5,486/5,486 passed
• git diff --check — passed

P1 — The requested race/failure regressions are still not causal end-to-end tests (confidence 100)

Evidence:

• crates/buzz-acp/src/pool.rs:8598-8601 says:

  assert!(resolver.lookup_project(id).await.is_err());
!resolver.projects.read().unwrap().contains_key(&id),
"an indeterminate lookup must not become cached absence"

• crates/buzz-cli/src/commands/projects.rs:821-825 says:

  assert!(verify_default_repo_write(
r#"{\"accepted\":true,\"message\":\"\"}"#,
Some(&matching),
channel

The ACP test calls the private lookup helper directly with malformed JSON. It does not exercise ChannelInfoResolver::resolve, prove that a failed/bounded lookup cannot render ordinary-channel context, or place the authoritative project beyond page one. The CLI test calls verify_default_repo_write directly with preconstructed values. It does not run cmd_create against a mocked relay that returns a dominated repository write plus a foreign winning head and assert that no project event is submitted; nor does it exercise the dominated-but-matching retry through the command path.

Concrete silent-pass scenario: a later refactor can preserve both helper tests while moving/collapsing the helper result at the caller, or publish the project before verification. The tests remain green while the exact two cross-boundary defects from the requested review return.

Required action: add the causal regressions Jude requested:

1. mock-bridge/page sequence with the authoritative project beyond page one, plus bound/timeout failure asserted through resolve so ordinary-channel context cannot be produced;
2. mocked cmd_create flow where a dominated repo write + winning head bound elsewhere fails with zero project publication, and a dominated-but-matching winner succeeds idempotently.

Production-path disposition

No new actionable security/adversarial defect found in the implementation itself:

• project and repository discovery are both #buzz-channel scoped;
• lookup failure is distinct from proven absence, is not cached on a cold miss, and an expired known value survives refresh failure;
• default-repo creation parses the write response, re-reads the addressable winner, and verifies its channel binding before project submission;
• the conflict resolution preserves main’s active-edit Escape handling and routed-edit behavior while retaining the project idle auxiliary drawer.

Current gate / residuals

GitHub reports the PR head at the reviewed SHA and MERGEABLE; new CI is still running, so this report does not claim a green terminal CI state. I found no additional deferred security residual requiring a separate issue beyond the actionable regression gap above.

Cassandra final security/adversarial re-review — exact head 7c630f5a9aca8eca7d851c35e9a8056e7b921ec9

Verdict: merge-ready from the security/adversarial lane; no actionable findings.

The prior causal-coverage P1 is closed:

• ACP now enters through the production resolver boundary and asserts that indeterminate discovery suppresses ordinary-channel context and caches no absence (crates/buzz-acp/src/pool.rs:8605-8613).
• The bridge regression supplies a full 500-event first page, requires #buzz-channel on every query, follows the composite cursor to page two, and resolves the authoritative project (pool.rs:8626-8686).
• CLI now drives real cmd_create calls through a mocked HTTP relay (crates/buzz-cli/src/commands/projects.rs:812-900). A dominated repository write whose winning head belongs to another home returns Conflict after posting only kind 30617 (:903-913); a matching winner proceeds idempotently and posts kinds 30617 then 30621 (:916-928). These assertions would fail if project publication moved ahead of winning-head verification.

I reviewed the full 86bf4946b..7c630f5a9 delta and independently reran at the exact SHA:

• cargo test -p buzz-acp -p buzz-cli — passed (including all three new causal regressions)
• git diff --check 86bf4946b..7c630f5a9 — passed
• post-run git rev-parse HEAD — 7c630f5a9aca8eca7d851c35e9a8056e7b921ec9

No new production code was introduced in this delta, and I found no test-harness silent-pass path that defeats the properties under review. GitHub reports this exact head as MERGEABLE; the newly triggered CI run is still in progress, so terminal CI remains the only unverified gate in this report. No new security residual requires a separate durable issue.

Gauge correctness/testing re-review — exact head 7c630f5a9aca8eca7d851c35e9a8056e7b921ec9

Reviewed the incremental lineage e1b1f1b8f..7c630f5a9 (fix commit 9ee5e05e4, merge 06dcc1807, ratchet refactor 86bf4946b, regression commit 7c630f5a9) against the fetched immutable SHAs. Findings formed before reading any other reviewer's round-4 output.

Both P1 fixes verified correct, with causal (mutation-verified) regressions

P1-1 — ACP indeterminate discovery. All four required properties hold at this head:

• Project filter is #buzz-channel-scoped: crates/buzz-acp/src/pool.rs — "kinds": [buzz_core::kind::KIND_PROJECT], "#buzz-channel": [channel] (pool.rs:3040-3042).
• fetch_project_home_for_channel returns Result<Option<PromptProjectInfo>, ProjectLookupError>; retry exhaustion maps to Err via .ok_or_else(|| ProjectLookupError("relay query failed or timed out after retry".into()))? (pool.rs:3071-3072).
• lookup_project caches only Ok; on Err with a prior cached value it serves stale (return Ok(stale.value);, pool.rs:644); on Err with no prior value it propagates Err (pool.rs:646).
• resolve() refuses ordinary-channel context on Err: "project context is indeterminate; refusing ordinary-channel context" → return None (pool.rs:611-615).

P1-2 — default-repo write verification. ensure_default_create_repo now does submit → parse_write_response (duplicate/dominated falls through) → fetch_own_repo_announcement re-read → require_repo_channel_binding on the winning head (crates/buzz-cli/src/commands/projects.rs:693-695, verify_default_repo_write at :699-717). Conflict fires before submit_project at the cmd_create call site (projects.rs:390).

Mutation verification — all three regressions are causally bound

I ran each regression against a reverted-defect mutant in a detached worktree at 7c630f5a9 (never touching the PR branch):

Unmutated full run at the exact head: cargo test -p buzz-acp -p buzz-cli → exit 0, buzz-acp lib 812 passed / 0 failed, no failures in any target. The CLI race regression also asserts the strongest possible postcondition — posted kinds are exactly [30617] on Conflict and [30617, 30621] on idempotent success.

Conflict resolutions verified

• FocusThreadDrawer.tsx: main's fix(messages): route edits to the owning composer #6575 hasActiveEdit prop retained (now optional with default, still wired: ChannelPane.tsx:513 hasActiveEdit={threadEditTarget !== null}), PR's label prop added.
• ChannelPane.tsx: main's edit-routing logic moved wholesale into useRoutedMessageEdit.ts (semantics preserved line-for-line, including the context-invalidation ref dance and "Finish or cancel your edit first." toast that messaging.spec.ts:3118/3337/3533/3589 assert on); PR's idle-auxiliary-panel behavior retained.

F1 (P2, confidence 100) — Rust Lint and Windows Rust CI failures at this head are real and author-owned

clippy::useless_vec in the new pagination test:

• Source: crates/buzz-acp/src/pool.rs:8637 — let responses = vec![
• CI: Rust Lint job 97592908638 — error: could not compile `buzz-acp` (lib test) due to 1 previous error / note: `-D clippy::useless-vec` implied by `-D warnings` ; Windows Rust job 97592909049 fails on the same lint (error: useless use of 'vec!').

One-line fix (array literal instead of vec![], as clippy suggests). This means the head needs one more push regardless, and the CI gate must be re-run fresh at the fixed head.

Note: just check / push hooks passing locally while clippy fails in CI means the local hook set does not run just clippy with -D warnings — worth knowing, not author work here beyond the fix.

Unit Tests CI failure — infra, not author work (confidence 100)

Job 97592908646: could not find native static library `sherpa-onnx-c-api` while building untouched buzz-voice. Same tooling failure Jude already classified as CI-owned at the previous head; unchanged by this PR.

F2 (P2, confidence 75) — same unverified-write pattern in the sibling channel-project path

crates/buzz-cli/src/commands/project_channel.rs:226 — client.submit_event(event).await?; in ensure_default_repo discards the write response and does no winning-head re-read before returning ChannelProjectRepo { repo_owner: caller, .. }. This is the exact defect class P1-2 fixed in projects.rs, in PR-introduced code (this file does not exist on main). A dominated write here leaves the channel-project flow claiming caller-owned repo authority it may not have. Either fix in this PR with the same submit→parse→re-read→bind pattern, or file as a durable residual — flagging for the author/Jude to scope.

Residual (confidence 50) — stale-retention path has no direct unit test

The Err-with-prior-cache branch (pool.rs:638-644, return Ok(stale.value)) is implemented but no test in pool.rs's test module exercises refresh-failure-with-cached-value (searched the test mod for retain/stale; the two new tests cover Err-without-cache and pagination). If this branch regressed to returning Err or dropping the cache, no test would fail. Small gap; follow-up material, not a blocker.

Verified clean at this head (scoped)

• No production-code changes in 7c630f5a9 itself (test-only: pool.rs test mod + projects.rs test mod — verified via diff).
• is_dm_channel correctly switched to resolve_channel_metadata so the author-gate DM check no longer depends on project lookup success (lib.rs:294).
• Desktop suite at the merge lineage: 5,486 tests claimed by Wrench; Desktop Core/E2E checks were green at 86bf4946b and are in progress at 7c630f5a9 — the clippy push will re-run them anyway.

Verdict: fixes and regressions are correct and causally tested; NOT merge-ready at this exact head. The useless_vec clippy failure requires one more push, and F2 needs an explicit scope decision. I'll re-verify the incremental diff and the full check-runs sweep at the next pushed head.

Cassandra security/adversarial re-review — exact head 73d4e2aaafa16156a40b986256038779277cb360

Verdict: merge-ready from the security/adversarial lane; no actionable findings.

I reviewed the full 7c630f5a9..73d4e2aaa delta and traced the sibling project_channel::ensure_default_repo path through preflight, submit, winning-head re-read, binding validation, and the subsequent project membership mutation.

Gauge F1 is closed: the full-page fixture is now an array, and the exact CI Clippy command passes.

Gauge F2 is closed with the same authoritative-write contract as project creation:

• crates/buzz-cli/src/commands/project_channel.rs:227-230 submits the repository, re-reads the caller's winning kind-30617 head, runs verify_default_repo_write, and only then calls try_add_own_repo_to_channel_project.
• The causal regression at project_channel.rs:425-487 drives the real helper through a mocked relay: empty preflight → dominated write → foreign winning head. It asserts Conflict and exactly three requests, so any attempted project update would make the server panic on the unexpected fourth request. This binds the ordering property rather than merely testing the verifier in isolation.

Independent exact-head verification:

• cargo clippy -p buzz-acp -p buzz-cli --all-targets -- -D warnings — passed
• cargo test -p buzz-acp -p buzz-cli — passed, including 377/377 buzz-cli tests
• git diff --check 7c630f5a9..73d4e2aaa — passed
• post-run HEAD — 73d4e2aaafa16156a40b986256038779277cb360

GitHub reports this exact head MERGEABLE; the newly triggered CI run remains in progress, so terminal CI is the only unverified gate. The previously noted stale-cache-retention coverage gap remains non-blocking and is already preserved in the PR review history; I found no new security residual requiring a separate issue.

Gauge round-5 review — head 73d4e2aaafa16156a40b986256038779277cb360

Verified independently in a detached worktree at the exact head (git rev-parse HEAD = 73d4e2aaa in the same shell as every check below).

Round-4 findings: both closed

F1 (clippy) — closed, confidence 100. cargo clippy -p buzz-acp -p buzz-cli --all-targets -- -D warnings passes locally at the exact head, and CI Rust Lint and Windows Rust (x86_64-pc-windows-msvc) are now green on this commit. The fixture is now an array (pool.rs:8637: let responses = [).

F2 (ensure_default_repo unverified write) — closed, confidence 100, mutation-verified. The fix follows the house pattern:

// project_channel.rs:227-229
let raw = client.submit_event(event).await?;
let winner = crate::commands::repos::fetch_own_repo_announcement(client, &repo_id).await?;
verify_default_repo_write(&raw, winner.as_ref(), channel)?;

The new regression ensure_default_repo_rejects_dominated_foreign_winning_head is causally bound: I reverted the three verification lines back to bare submit_event in the worktree and the test fails (panicked at crates/buzz-cli/src/commands/project_channel.rs:479); restored, it passes. The request-count assertion (requests == 3, "verification must fail before trying to update the project") proves it stops before project membership update. Full unmutated suites at this head: cargo test -p buzz-acp -p buzz-cli — buzz-acp 812/812, buzz-cli 377/377, all green.

New finding — not merge-ready at this head

F3 (P1, confidence 100): Desktop Smoke E2E (3) fails deterministically at this head, and it is PR-caused.

CI failed project-conversation-load-failure.spec.ts:73 on all 3 attempts. I reproduced it locally at the exact head — fails identically in an isolated run and in a full --shard=3/4 run:

Error: locator.click: Test timeout of 30000ms exceeded.
  - waiting for getByRole('tab', { name: 'Channels', exact: true })
> 151 |     await page.getByRole("tab", { name: "Channels", exact: true }).click();

Mechanism: this PR's bridge change gives the mock "buzz" project an authoritative home binding —

// e2eBridge.ts:5997-6002 (project event tags)
[
  "buzz-channel",
  getConfig()?.mock?.projectAccessChannelId ??
    STARTER_PROJECT_HOME_CHANNEL_ID,
],

so ProjectDetailScreen.tsx:681 (const showChannelHome = hasAuthoritativeHomeBinding(project) && ...) now renders ProjectChannelHome, which has no "Channels" workspace tab. The page snapshot at failure confirms the new home surface (breadcrumb + Overview, no tablist).

The spec expecting the old tabbed landing entered this branch from main (#6447, f6e6617a9) via the conflict-resolution merge 06dcc1807. The PR correctly adapted its own pre-existing specs — e.g. project-issue-comments.spec.ts:24 added await page.getByTestId("project-home-context-repo-buzz").click(); — but the merged-in spec was never swept. This is the same mechanism as PR#6595's F1→F7 chain: when a PR changes a landing/navigation contract, the closed set of specs entering that surface includes specs that arrive from main during a merge, not just the ones the PR authored. Grep for the closed set at this head: rg -l 'project-card-buzz|project-row-buzz' desktop/tests/e2e/ → 6 spec files; 5 were adapted, project-conversation-load-failure.spec.ts was not.

Why local verification missed it: just desktop-test and the push hooks run the unit/check suites, not the smoke e2e shards — the first completed smoke run on the merged lineage was this CI run (smoke shards at 86bf494 and 7c630f5 were cancelled as superseded).

F4 (confidence 50): possible order-dependent instability in shard 3 messaging specs. CI also failed messaging.spec.ts:2049 ("sends a thread message … root-thread link") on all 3 attempts, but at the exact same head it passes locally in isolation AND in a full messaging.spec.ts run (85/85); my local --shard=3/4 run instead failed a different messaging spec (avatar attribute). I cannot causally bind this to the PR (hence 50, not 75). Watch the next CI run after the F3 fix: if 2049 fails again, treat it as real and PR-adjacent (the new mock channel in mockChannels is the only bridge-state change in scope).

Verified clean at this head

• cargo clippy -p buzz-acp -p buzz-cli --all-targets -- -D warnings — pass.
• cargo test -p buzz-acp -p buzz-cli — pass (812 + 377 + 9).
• Mutation test binding the F2 regression to its defect — pass/fail as expected.
• CI: Rust Lint, Windows Rust, Desktop Core, Desktop E2E Integration (both shards), Relay E2E, Desktop Build (macOS), cross-compiles, Security, DCO — all green at this commit.
• Unit Tests CI failure is the known sherpa-onnx native-lib infra issue (could not find native static library sherpa-onnx-c-api) — CI-owned, not this PR (same as Jude classed previously).

Residuals (unchanged)

• Stale-retention branch (pool.rs:644) still has no direct unit test — follow-up, not a blocker.

Cassandra re-review — b4e1d8c13c795dc799f6d8dfaee1be7fb532114b

Verdict: merge-ready from the security/adversarial lane; no actionable findings.

F3 is closed. The incremental diff adds the missing repository-context transition at desktop/tests/e2e/project-conversation-load-failure.spec.ts:151 before selecting the repository workspace's Channels tab. I traced this against the equivalent bound-home navigation used by the sibling project specs and independently ran the exact smoke spec at this exact head: 1/1 passed. git diff --check 73d4e2aa..b4e1d8c1 also passed.

Coverage: full one-line incremental diff, surrounding navigation and failure/retry path, sibling bound-home project flows, exact smoke execution. No new security, correctness, or test-causality defect found. No durable residual arose from this delta.

GitHub reports the exact head MERGEABLE; the fresh CI run is still in progress, so terminal CI remains the only unverified gate. F4 remains unbound and is not promoted: the formerly reported messaging.spec.ts:2049 failure passed Wrench's rerun and this delta does not touch that path.

Gauge round-6 review — head b4e1d8c13c795dc799f6d8dfaee1be7fb532114b

Verdict: merge-ready from the correctness/testing/reliability lane. F3 closed, F4 did not reproduce, CI terminal-green at this exact head.

F3 — closed (confidence 100)

The delta from 73d4e2a is exactly one line:

desktop/tests/e2e/project-conversation-load-failure.spec.ts | 1 +

project-conversation-load-failure.spec.ts:151 now clicks project-home-context-repo-buzz before getByRole("tab", { name: "Channels", exact: true }) — the identical entry pattern used by the five previously-adapted specs (e.g. project-issue-comments.spec.ts:24, project-pr-review.spec.ts:64).

Independently verified at this exact head in my detached worktree (git rev-parse HEAD = b4e1d8c1… in the same shell):

• Ran the exact spec via playwright test tests/e2e/project-conversation-load-failure.spec.ts --project=smoke → 1 passed (3.7s).
• Closed-set sweep re-run at this head: git grep -l 'project-card-buzz|project-row-buzz' -- desktop/tests/e2e/ → 6 files; all 6 now enter the bound-home surface via project-home-context-repo-* before selecting workspace tabs (commit-detail, conversation-load-failure, issue-comments, pr-review, v3-screenshots, terminal-wheel). No remaining spec reaches workspace tabs from the old unbound landing. Negative claim scoped to that grep set.

F4 — did not reproduce; unbound as predicted (confidence stays ≤50, no action)

Desktop Smoke E2E (3) — the shard containing messaging.spec.ts:2049 — completed success on this head's fresh CI run. Combined with Wrench's local isolation + full-file pass at the prior head, this stays classified as a non-deterministic flake not caused by this PR. Residual only; nothing to fix here.

Terminal CI gate — green (confidence 100)

Polled repos/block/buzz/commits/b4e1d8c…/check-runs to terminal state: 0 pending, 0 failures. All four Desktop Smoke shards, Desktop Core, Desktop E2E Integration/Relay, Unit Tests, Rust Lint, Windows Rust, Mobile, Security, builds — all success (Web and manifest merge skipped by path detection, expected). This is the first fully-green terminal CI run on this PR's merged lineage. The previously CI-owned sherpa-onnx Unit Tests failure also cleared on this run.

mergeable: MERGEABLE; mergeStateStatus: BLOCKED is the required-approval gate, not CI.

Residuals (durable, non-blocking)

• (50) pool.rs:644 stale-retention branch still has no direct unit test — carried from round 5, follow-up material.

Nothing else outstanding from my lane across rounds 4–6: both original P1s, F1 (clippy), F2 (ensure_default_repo lost-write), and F3 are all closed with causally-bound regressions.